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Abstract 

Type classes are an elegant extension to traditional, Hindley-Milner based typing systems. 
They are used in modern, typed languages such as Haskell to support controlled overloading 
of symbols. Haskell 98 supports only single-parameter and constructor type classes. Other 
extensions such as multi-parameter type classes are highly desired but are still not officially 
supported by Haskell. Subtle issues arise with extensions, which may lead to a loss of feasible 
type inference or ambiguous programs. A proper logical basis for type class systems seems to 
be missing. Such a basis would allow extensions to be characterised and studied rigorously. 
We propose to employ Constraint Handling Rules as a tool to study and develop type class 
systems in a uniform way. 

1 Introduction 



The Haskell language ]PHA + 9S ] provides one of the most advanced type systems in an industrial- 
strength language. Type classes are one of the most distinctive features of Haskell. The form 



of type classes found in Haskell 98 is restricted to single-parameter and constructor |Jon93| type 
classes. A rigorous treatment of the Haskell 98 type system can be found in in Jon99], it fills some 
serious gaps in the current sp ecifications of H askell. 

Since the original papers | Kae88 WB89| on type class es, many researchers have studied ex- 
tensions to the existing type class system [ CHQ92 , JJM97]. In particular, multi-parameter type 
classes are a very desirable extension, see [JJM97] for an overview. However, multi-parameter type 
classes are still not officially supported by Haskell. As the authors note, design decisions need to 
be taken with great care in order to retain feasible type inference. 

Existing implementations of Haskell use a dictionary passing translation to support type class 
overloading. This requires types to be unambiguous, otherwise an implementation can't know 
which dictionary should be passed. Unfortunately, even with the existing single-parameter class 
system, ambiguous types can occur. In his recent paper JonOC], Jones extends type classes with 
functional dependencies to resolve ambiguity in the context of multi-parameter classes for certain 
cases. We find that type classes are still an active area of research and the debate about which 
features should be incorporated into future Haskell specifications is far from settled. 

This work. In contrast to previous work, our foremost goal is not to propose yet another extension 
of type classes. The thesis of this paper is: Constraint handling rules t Fru9!\ ] are the right way to 
understand type class constraints, and extensions to type classes. In particular, constraint handling 
rules help us understand the two main issues behind possible type class extensions: Feasible type 
inference and unambiguous programs. 
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Feasible type inference is an important property which needs to be retained when considering 
type class extensions. Type inference should be decidable and should compute principal types. 
Hindley-Milner types are characterized by constraints that are representable using Herbrand con- 
straints, and solvable using well-understood constraint solvers such as Robinson's unification algo- 
rithm. Clearly, type classes are simply another form of constraint system, extending the Herbrand 
constraints, that constrains the value that various type variables can take. 

Constraint handling rules (CHRs) are a way of extending constraint solving from a well- 
understood underlying constraint domain to handle new forms of constraints. CHRs are a simple 
language and efficient implementations are available. They give a natural definition of a constraint 
solver for type classes, they clarify some issues about what meaning should be given to type class 
extensions and they give insight into problems such as ambiguity, overlapping instances of type 
classes and multi-parameter type classes. Moreover, CHRs allow us to specify the conditions under 
which feasible type inference is guaranteed. 

For the purpose of this workshop paper, we explain our ideas by example rather than by giving 
a rigorous formal treatment. 

Outline. Section || motivates our approach by reviewing limitations with Haskell's type class 
system, which can be overcome with extensions defined by CHRs. In Section ||, we review the 
basic ideas behind CHRs. Type inference is described in Section^. Section || states some sufficient 
conditions under which we achieve feasible type inference and unambiguous programs. In Section 0, 
we show how to express some (previously proposed in the literature) type class extensions in terms 
of CHRs. In Section g, we show that CHRs prove to be useful for defining novel type class 
extensions. We conclude in Section pi 



2 Motivation 

Type classes are an elegant extension to traditional, Hindlcy-Milner based typing systems. In 
addition to supporting controlled overloading of functions they allow programmers (and language 
designers) to identify related types. For example, when we make our new type an instance of the 
Eq class; not only are we adding the convenience of the == operator we are telling users of this 
type that its inhabitants are exact and identifiable. Note that if we choose not to make our type 
an instance of Eq we are also making a statement: inhabitants are representing values which are 
inexact and/or hard to identify. 

Unfortunately, in Haskell 98 it is impossible to enforce any restrictions on class membership. 
Worse, instance declarations are global and a program can only have one instance declaration for 
a type and a particular class. This requires that any instance declaration visible in a module is 
exported to all modules which import it, bypassing Haskell's name hiding mechanisms. So, if a 
module declares Bool to be a member of the Num class then any importing module also treats 
Booleans as a member of Num. The writer of the importing module may be completely unaware 
that this has happened. Now 'errors' such as 

import X() — X makes Bool an instance of Integral 

cap_power : : (Num a, Integral b) => Bool -> b -> a -> b -> a 
cap_power useLimit theLimit n p 

I useLimit && theLimit < p = n useLimit — surely intended 'theLimit' 

I otherwise = n " p 

will compile just fine, though with bizarre consequences. 

Many researchers have studied extensions which would make them more useful, while main- 
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taming Haskell's decidable type inference. In particular, extensions have been proposed to support 
multi parameter type classes and allow relationships amongst components of a type class other 
than the standard super/sub class relations. These extensions are ad-hoc, requiring special syntax 
and 'hidden' restrictions to be added to the language in order to guarantee principal types and a 
decidable type inference algorithm. 

CHRs provide a framework which allows much more freedom for the programmer and language 
designer to specify constraints on type classes. These extra constraints can serve both to make 
more programs typable (since the more powerful constraints remove potential ambiguity of types 
in a program) and to make less programs typable (since the class constraints can restrict the use 
of types to those intended by the class writer) . 

CHRs will be described in the next section, but for the remainder of this section we will 
introduce some examples to give a feel for how CHRs can make the language both safer and more 
expressive. 



2.1 Disjoint Classes 

Haskell 98 's support for type classes is too restrictive even without adding multi-parameter type 
classes to the language. For example, we would like to say that the Integral and Fractional 
type classes are disjoint. This cannot be expressed in current Haskell and hence the function 

fxy=x/y+x 'div' y 

has an inferred type of f :: (Integral a, Fractional a) => a -> a -> a rather than imme- 
diately causing a type error. 

Disjoint classes can also be used to resolve ambiguities in a program. Overlapping type class 
instances are a thorny issue for Haskell implementations. In general, overlapping instances lead to 
unacceptable ambiguity in programs. But with improved class information it would sometimes be 
clear that overlapping instances do not really overlap at all. For example imagine a "has division 
operator" class Dividable defined as follows: 

class Num a => Dividable a where dividedBy : : a -> a -> a 

instance Fractional a => Dividable a where dividedBy = (/) 
instance Integral a => Dividable a where dividedBy = div 



half ish : : Dividable a => a -> a 
halfish x = x 'dividedBy 1 2 

Although the instances appear to overlap, we know that the Integral and Fractional type 
classes are intended to be disjoint, therefore there should be no ambiguity here. Notice that this 
also implies a further extension to GHC's existing, experimental support for overlapping instances. 
Currently, GHC ignores the instance constraints when deciding if two instance declarations overlap. 

A special case of disjoint sets allows us to specify instance declarations for certain types to be 
an error. For example, we could add constraints to the prelude so that programmers can't make 
types such as Bool, Char and function types instances of the Num class. This can be done directly 
for each type or we can declare a disjoint set for Num, e.g. NotNum, and make the types instances 
of this disjoint class. 



2.2 Multi-Parameter Classes 



As Jones [lonOC] points out, the need to extend type classes to a relation over types is well under- 
stood, and most Haskell implementations support multi-parameter type classes by non-standard 
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extensions. However, in practice they haven't worked as well as was hoped. Many useful programs 
have ambiguous types or fall foul of syntactic restrictions required for feasible type inference. By 
allowing more expressive constraints between the elements of a class relation, these programs can 
be typed, and in addition the class designer has finer control over their use. Below, we show some 
useful relationships using the Collects class, as presented by Jones, as an example. 



class Collects e ce where 
empty : : ce 

insert : : e -> ce -> ce 
member : : e -> ce -> Bool 

Functional Dependencies Jones proposes to extend type classes with Functional Dependencies 
to support dependencies amongst Class components. These give the programmer the neces- 
sary control over the allowed relationships to allow additional programs to be typed. The 
empty method of Collects has an ambiguous type (since only ce is fixed and there may 
be more than one possible instance declaration which could be used). But if we say that 
the type of e is dependent on the type of ce, it is no longer ambiguous. CHRs subsume the 
expressiveness of functional dependencies. The remaining examples are not possible with 
only functional dependencies, however they are supported by CHRs. 

Anti-symmetrical Relations The Collects class allows us to declare that [a] is a collection 
of as by an instance declaration for Collects a [a] . However, it would never be sensible 
to declare an instance for the reverse, i.e. Collects [a] a. CHR's can specify that the 
relationship is anti-symmetrical, making the latter instance declaration a type error. 

Irreflexive Relations The Collects relation is also irreflexive, it wouldn't be sensible to allow 
a type to be a collection type for itself, i.e. Collects n T2 where n and ti are unifiable. 

Many other relationships, such as transitivity or symmetry, can also be expressed with CHRs. 



2.3 Constructor Classes 

Type constructors, such as List (actually, [] ) or ->, are functions over types. Implicitly each type 
constructor has a Kind which specifies the number of argument types required to produce the 
result type. 

Constructor classes, which are supported by Haskell 98, allow the programmer to write a class 
over type constructors. Then, any type constructor with the correct kind can be made an instance 
of the class, e.g. the definition of the Functor class in Haskell 98 is: 

class Functor f where fmap : : (a -> b) -> f a -> f b 

Instances can be provided for [] and Tree but not for Int or ->, since they don't have the correct 
kind. 

Instead of introducing a kind system to Haskell, we could use CHRs to express these constraints 
as multi-parameter class constraints. The CHR system can explicitly describe the required con- 
straints, i.e. the type constructor is functional, surjective and correctly kinded. 



3 Constraint Handling Rules 



Constraint handling rules | Fru95| (CHRs) are a multi- headed concurrent constraint language for 



writing incremental constraint solvers. In effect, they define transitions from one constraint set to 
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an equivalent constraint set. Transitions serve to simplify constraints and detect satisfiability and 
unsatisfiability. Efficient implementations of CHRs are available in the languages SICStus Prolog 
and Eclipse Prolog, and other implementations are currently being developed (e.g., for Java). 

CHRs manipulate a constraint set in two parts: a global constraint in the language of the 
underlying solver, and a global set of primitive constraints defined only by constraint handling 
rules. 

Constraint handling rules (CHR rules) are of two forms (though the first is sufficient) 

simplification rulename@Ci, . . . , c„ •<=>■ g \ d\, . . . , d m 
propagation rulename@C\, . . . , c n ==>■ g \ d\, . . . , d m 

In these rules rulename is a unique identifier for a rule, ci, . . . ,c„ are CHR constraints, g is a 
Herbrand constraint, and di, ■ ■ ■ , d m are either CHR or Herbrand constraints. The guard part g 
is optional. When it is omitted it is equivalent to g = True. The simplification rule states that 
given a constraint set {ci, . . . , c„} where g must hold, this set can be replaced by {di, . . . , d m }. 
The propagation rule states that given a constraint set {ci, . . . , c„} where g must hold, we should 
add {di, . . . , d m }. A CHR program is a set of CHR rules. 

More formally the logical interpretation of the rules is as follows. Let x be the variables 
occurring in {ci, . . . , c„}, and y (resp. z) be the other variables occurring in the guard g (resp. rhs 
di, . . . ,d m ) of the rule. We assume no local variables appear in both the guard and the rhs. The 
logical reading is 

simplification \fx(3y g) — > (ci A • • ■ A c„ «-> (3z d± A • • • A d m )) 
propagation \fx(3y g) — ¥ (ci A • • • A c n — > (3z d\ A • • • A d m )) 



The operational semantics (see [Abd97| for more detail) is a transition system on a quadruple 
(/, s, h, t) v of a conjunction of CHR and Herbrand constraints /, a conjunction of CHR constraints 
s, a conjunction of Herbrand constraints h, a set of tokens for use in controlling termination and a 
sequence of variables v. The logical reading of (/, s, h, t) v is as 3yf As Ah where y are the variables 
in the tuple not in v. Since the variable component v never changes we omit it for much of the 
presentation. 

Tokens take the form r@h where r is a rulename of a propagation rule, and h is a conjunction of 
CHR constraints matching the left hand side of the rule. In order to avoid trivial non-termination 
with propagation rules, which if they are applied once can be applied again, the operational 
semantics restricts that a propagation rule can only be applied once to each set of matching CHR 
constraints. Tokens are introduced when a new CHR constraint is moved to the store s, and used 
up on the application of a propagation rule. Define token(c, s) to be the set of new propagation 
rule applications which could be applied when adding CHR constraint c to a CHR store s. 

token(c, s) = {r@c A c' | (r@c" => g\b) £ P, s = c' A s' , \= 3((c A c') = c")} 

Tokens are removed through the use of propagation rules, and when they are no longer applicable 
through a simplification 

solve (d A /, s, h, t) >— > (/, s, h', t) 

d is a Herbrand constraint, |= b! <-» h A d 
introduce (d A /, s, h, t) >— * (/, s A d, h, t U token(c, s)) 

d is a CHR constraint 
simplify (/, d A s, h, t) (d A /, s, h A c = d, t — U c ' 6c <tofcen(c£, d A s)) 

r@c 4=> g | d in P and |= h — * 3x(c = d A <?) 
propagate (/, d A s, h, t U {r@c'}} >^p (d A f,d A s, h A c = d, t) 

r@c 5 | d in P and |= /i — > 3x(c = d A g) 
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where x are variables (assumed to be new) appearing in the CHR used. Note that the components of 
the triple are treated as conjunctions and the matching is modulo the idempotence, commutativity, 
and associativity of conjunction. 

An important property of CHR programs is confluence. Confluence implies that the order 
of the transitions doesn't affect the final result. Two states (/i, s%, hi, t\) v and (/ 2) S2, /i2> *2)u 
are joinable if there exists derivations (/i, s±, hi, t%) v >— (fs, S3, 113, £3},, and (/2, s 2 , h,2, £2)1; 
(fi, S4, /14, tz) v such that (/3, S3, h^,t^) v is a variant of (/4, S4, Confluent CHR programs 

are guaranteed to be consistent (in the usual sense of a theory). 

A CHR program P is confluent iff for each state (/, s, h, t) v , if (/, s, h, t) v >-^p si,hi, t\) v 
and {f,s,h.t) v (/ 2 , s 2 , h 2> h)v then (fx, si, h x ,ti) v and {f 2 , s 2 , h 2 ,t 2 ) v arc join able. 



Importantly, for terminating CHR programs, confluence is decidable [Ahd97] (although ter- 
mination is not decidable). This is because for these programs, confluence is equivalent to local 
confluence which we can test by examining each critical pair of the program and seeing whether 
they are joinable. A critical pair of two rules 

ri @ci A c[ <^=> gi I di r 2 @c 2 A c' 2 g 2 \ d 2 

is the pair of states (ci A d 2 ,True, g\ l\g 2 A d x = c 2 , 0} and (c 2 A d\,True, g\/\g 2 /\ c[ = c' 2 , 0} where 
9i A g 2 A c[ = c' 2 is satisfiable. 

Deciding confluence requires that the CHR program is terminating. There are a number of 
syntactic restrictions on Haskell class and instance declarations that will assure us that the re- 
sulting CHR programs are terminating. There are also a number of other approaches to proving 



termination of CHR programs [Fru' 



4 Type Inference 

Haskell is an implicitly typed language. The task of type inference is to infer a type for a given 
program or report error if the program is not typable. We identify the following three issues: 

1. Class and instance declarations must be correct. 

2. Type inference must generate a correct set of constraints which represent the possible solu- 
tions to the typing problem. The program is typable if the constraint problem is solvable. 

3. Simplification of constraints is important for two reasons. Syntactically, it allows us to 
present type class constraints to the programmer in a more readable form. Operationally, 
simplification allows us to put type class constraints into a more efficient form. Type class 
constraints are translated into dictionaries. Hence, simplifying type class constraints may 
allow a more efficient translation. This form of simplification is known as context reduction 
in Haskell. 

Type inference starts by processing all class and instance declarations, i.e. we translate all class 
and instance declarations into a CHR program. Then, type inference generates the constraints of 
the Haskell program and applies the CHR solving process. In CHR, a constraint C is solvable if 
the derivation from C does not lead to a constraint including False. Simplification may be invoked 
if necessary. The following three sections expand on the three issues. 



4.1 Class and instance declarations 

In this section we show how to translate class and instance definitions into CHRs. 
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Class definitions 

A class definition 

class (e?i, . . . , d m ) => C X\ ... x n where . . . 

constrains any instance of the class C to also satisfy the class constraints d\, . . . , d m . Hence the 
corresponding CHR is 

C x\ ... x n )' d\ , . . . , d m 

Example 1. Consider the standard prelude definitions of Ord and its translation: 

class Eq t => Ord t where . . . Sl@Ord t => Eq t 
Whenever we assert the Ord t constraint we must also satisfy the Eq t constraint, rj 

Instance definitions 

An instance definition 

instance (di, . . . , d m ) => C ti . . . t n where . . . 

maintains that tuple t\ ... t n is an instance of C if the constraints d\ , . . . , d m are also satisfied. 
This corresponds to a simplification rule. 

C t\ ... t n 4=> d\, . . . , d m 

Example 2. The instances of Ord and Eq for Lists and their translations are: 

instance Eq t => Eq [t] where . . . S2@Eq [t] Eq t 
instance Ord t => Ord [t] where . . . S3@Ord [t] Ord t 

This means that we can prove that a type [t] is an instance of the class Eq or Ord if and only if 
we can prove that t is an instance, rj 

Checking instance definitions 

An instance declaration must be compatible with the class definition. An instance declaration is 
correct in this sense if the resulting CHR program is confluent. 

Example 3. If the instance declaration for Ord [t] didn't require that t was also in class Ord, 
i.e. 

instance Ord [t] where . . . SA@Ord [t] <^=> True 

We would have a non-confluent CHR program, since Ord [t] has two derivations whose result is 
not joinable: 

(Ord [t], True, True, 9} {t} 
>-► (True, True, Ord [t], {Sl@Ord [t]}) {t} 
Sl@ Ord [t] => Eq [t] >-► (Eq [t],True,Ord [t],0) w 

>-> (True, True, Ord [t] A Eq [t],<D) {t} 
SA@ Ord [t] <s=> True >-► (True, True, Eq [i],0) w 
S2@ Eq [t] Eq t >-> (Eq t, True, True, 0) {t} 
^ (True,True,Eqt,$) {t} 
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and 

(Ord [t], True, True, 0){t} 
>-> (True, True, Ord [t],{Sl@Ord [t\}) {t} 
S4@ Ord [t] <=> True >-> (True, True, True, 0} {t} 

□ 

After generating a CHR program we can (assuming that its terminating) check that it is 
confluent. If it isn't confluent then there is an error in the instance declarations, otherwise we can 
safely use the CHR program for type inference. 

4.2 Solving Type Class Constraints 

With this view of type classes simply as constraints defined by CHR rules, the solving process is 
obvious: generate the constraints of the program text and apply the CHR solving process. 

Example 4. Consider the Haskell function 

f g h = c where a = tail g; b = init h; c = a < b 

the constraints generated are 

t a = [h] At g = [<!] A t b = [t 2 ] A t h = [t 2 ] A t f = t g ^ t h >-> t c A 



Ord ^3 A ^3 i — > *3 i — > Bool = t a i— ► t b t c 



(1) 



Note that we use subscript notation to associate expressions and their inferred type. After simpli- 
fication through unification we obtain 

ta=tg = t b = t h = h = [t{\ A t 2 = h A t f = [ii] i > [fi] i ► Bool A Ord [h] (2) 

If we now apply the constraint handling rules above to the constraint Ord [ti] we obtain the 
following derivation: 

(Ord [ti], True, True, 0) {tl} 
~ (True, Ord [t{\,True,{Sl@Ord [*i]}) {tl} 
Sm Ord [ii] Ord h >-► (Ord t u True, True, 0} {tl} 

>-► (True, Ord h, True, {Sl@Ordh}) {tl} 
SI® Ordti=> Eqh >-» (Eq ti, Ord ti, True, 0) {tl} 

^* (True,Eqti AOrdti,True,9) {tl } 

Since such derivations are laborious, from now on we will use simplified derivations where the tuple 
is represented as a single conjunction and unification is applied to remove extra variables, and the 
token set is omitted. The corresponding derivation is 

Ord [ti] Ord t\ >—>si Ord ti A Eq t\ 

Since the CHR program is confluent, all alternative rewritings must (eventually) give the same 
result, for example 

Ord [ti] ^si Ord [h] A Eq [ti] ^ S 2 Ord [*i] A Eq t Y ^S3 Ord t\ A Eq ti 

gives the same answer, rj 
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4.3 Presenting Type Class Constraints 



CHRs are also simplification rules, they replace a (type class) constraint by a simpler, equivalent 
form. When we want to present a type definition to the user we wish to have the "simplest" 
possible form. This is contrary to the usual solving methodology that adds redundant information 
to simplify the detection of unsatisfiability. To this end it is worth adding a separate simplification 
phase for presenting constrained types to users. This too can be represented by a (disjoint) CHR 
program. 

The presentation rules for class definition 

class (d\, . . . ,d m ) C x\ ... x n where . . . 

are of the form C x\ ... x n , di ■<=>■ C x\ ... x n which removes the redundant constraints for 
presentation. 

Example 5. An example class definition and its corresponding presentation rule are: 

class Eq t => Ord t where ... Pl@Ord t, Eq t Ord t 

In presenting the answer to Example || we obtain the type f : : Ord t => t -> t -> Bool since 
Ord ti , Eq t\ >— »pi Ord t\. rj 

5 Properties of Type Class Systems 

CHRs allow us to characterize under which conditions we retain feasible type inference and unam- 
biguous programs. 



5.1 Feasible Type Inference 

Feasible type inference must be decidable and yield principal types. In CHR, type inference is 
decidable if the CHR program is terminating. If we restrict instance and class definitions to those 
allowed by the Haskell report and GHC's multi-parameter type class extensions then the resulting 
CHR program is always terminating. 

Principality means that for a given Haskell program the inferred type subsumes all other types 
we could possibly give to this program. CHRs preserve principal types because they only ever 
map constraints to logically equivalent constraints. Note that principal types are not syntactically 
unique (in Example [|, (|l|) and (|J) are both possible principal types) but since the CHR program 
is confluent, we will always present the same type. 

Confluence of the CHR program is a vital property. It guarantees that the CHR program is 
consistent, so we can meaningfully talk about unsatisfiable type constraints, and it guarantees that 
instance definitions satisfy class definitions. 



Type Signatures 

Type signatures allow the user to declare that variables have a certain type. They are an optional 
form of program documentation but necessary, for example, to retain decidability in the case of 
polymorphic recursion. In the presence of type signatures, we are moving from a type inference 
problem to a type reconstruction problem. This shift implies that our constraint solver also needs to 
handle entailment among constraints. Decidable constraint entailment is often difficult to establish. 
As in [Jon99|, we find that the conditions of Haskell 98 are sufficient to guarantee that entailment 
is decidable. 
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5.2 Unambiguous Types 

In the Haskell framework each function must have an unambiguous type. We can understand the 
notion of unambiguity in terms of CHRs, so that later when we extend the type system to use 
more complex CHRs we retain this property. 

Suppose the inferred type for function / is / :: D r then the type for / is unambiguous for 
CHR program P if, for renaming to new variables p, P \= D A p(D) A r = p(r) — » a = p(a) for 
each variable a € vars(D r). 

We have a sound check for the unambiguity of a type using the CHR program P by seeing 
if D A p{D) At = p(r) C where |= C — > a = p(a). This check is complete for Haskell 98 
programs, ignoring Haskell's Numeric defaulting mechanism. We conjecture that it is complete for 
other interesting Haskell extensions, such as Functional Dependencies. 

Example 6. Recall the Collects example from Section |[ The type of empty is empty :: 
Collects e ce =>■ ce. This type is ambiguous, because 

Collects e ce A Collects e ce' A ce = ce 

does not allow any propagation steps, and does not imply that e = e! '. 

The type defined for insert is insert :: Collects e ce =4> e t— > ce t— » ce which is clearly 
unambiguous, rj 



6 Understanding Type Classes Extensions 

There are a number of extensions to type classes that have been proposed in the literature. These 
can be understood in the uniform framework of CHRs. By unifying the representation of different 
extensions we can gain insight into what kinds of extensions are feasible. 



Functional Dependencies 



Jones [JonOO proposes an extension of multi-parameter type classes to include functional de- 
pendencies among class arguments. From a CHR point of view, functional dependencies among 
variables in a type class just extend the proof requirements for an instance. They are expressible 
straightforwardly using CHRs. 

A class definition with functional dependencies has the form 

class (di, . . . , d m ) =>■ C x\ ... x n \ fd ± , . . . ,fd k where . . . 



where fd i is a functional dependency of the form (x^, . . . ,Xi k ) ~» Xj . In [JonOOj the rhs of the 
can have a list of variables. We use this simpler form, the expressiveness is equivalent. The 

functional dependency asserts that given fixed values of , . . . , Xi k then there is only one value of 

Xi for which the class constraint C x\ ... x n can hold. 

The CHR translation creates a propagation rule for each functional dependency of the form 

C x\ ... x n , C yi ... y n ==> Xi l = yi ± A • • • A Xi k = yi k | Xi — yi a 

This CHR enforces the functional dependency. 

Example 7. Returning to the collection class example, but now adding a functional dependency. 
We have the following rule and (simplified) CHR: 

class Collects e ce | ce e where ... Tl@Collects e ce, Collects f ce ==> / = e 
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Note now that the type for empty is unambiguous because 
Collects e ce A Collects e ce A ce — ce' >— ►yi Collects e ce A Collects e ce' Ace — ce' A e = e' 

□ 

Example 8. The type checking/inference for 

f x y c = insert x z where z = insert y c 
where insert : : Collects e ce => e -> ce -> ce gives 

Collects e ce A e i — ► ce i — ► ce = ty i — > t c i — ► t 2 A Collects e ce' Ae'n ce' i— > ce' = i— > i z h 
= Collects e ce A Collects e' ce At c — t z — ce' = r = ce At y = e At x — e' 
>—>ti Collects e ce A Collects e ce At c = t z = ce = r = ce At y = e At x = e Ae = e 
= Collects e ce A t c = t z = ce' — r — ce A t x — t y — e 

The type inferred is f : : Collects e ce => e -> e -> ce -> ce as expected, rj 

This view of functional dependencies as CHRs clarifies one of the questions that Jones poses 



in the end of | Jon00|. Given the declarations 



class U a b \ a b where... 
class U a b V a b where... 

in Jones' framework, from the constraints U a b AV a c it cannot be inferred that b — c. The CHR 
rules support the automatic inference of inherited functional dependencies Consider the following 
example: 

UabAVac ^ UabAVacAUac >-> U a c A V a c A b = c 
Constructor Classes 

Type constructors are simply a functional relation among types. We can understand them simply 
using CHRs, this is simply a matter of replacing constructor expressions / e (lets say = fe) 
by explicit kind constraints Kind*->* / e fe. The class constraints need to satisfy appropriate 
properties (functionality, surjectiveness) which can be expressed with CHRs, as well as the kind 
constraints. For example 

functional @ Kind*->* / e fe, Kind*->* / e fe =$> fe = fe 
surjective @ Kind*->* / e fe, Kind*->* /' e' fe / = /', e = e' 

kinding @ Kind*->* / e fe, Kind* / False 

Clearly constructor classes can be expressed using CHRs, and hence we have a more uniform 
understanding of their meaning and use. The presentation of constructor class constraints to the 
user might be preferable with the usual notation, but this is simply a matter of presentation. 

7 Further Extensions to Types Classes Using CHRs 

Given we can use CHRs to specify existing type class extensions, an immediate question is what 
other new extensions can we express in terms of CHRs. 
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Disjointness of Type Classes 

The example in Section || illustrates how it may be useful to have additional constraints on the 
instances of a class. With this disjointness we may be able to have a weaker definition of non- 
overlapping instances. 

Example 9. A CHR expressing that the Integral and Fractional type classes are disjoint is 
simply. 

IF@Integral t, Fractional t False 

If we translate the two instance declarations for Dividable from the motivation we obtain: 

DIl@Dividable t Integral t 
DFl@Dividable t Fractional t 

Clearly the resulting CHRs are not confluent, since there are two disjoint replacements for Dividable t. 
But we could weaken the simplification rules to 

DI2@Dividable t, Integral t -4=> Integral t 
DF2@Dividable t, Fractional t <==^ Fractional t 

which together with (IF) give a confluent system. Note that with this reading, we can remove a 
Dividable t constraint if we already know that t is in Integral or Fractional but we cannot simply 
replace the Dividable t with one of these constraints, rj 

Another extension is to allow negative information about type classes. 

Example 10. The intention of the Num class is to describe numeric types. We might insist that 
functional types are never numbers by adding the rule 

Nl@Num (s i ► t) ^=^> False 

Or we might form a NotNum class meant to indicate types which cannot be numbers, where func- 
tional types are in this class, expressed by the rules 

N2@NotNum t, Num t False 
N3@NotNum (s i-v t) True 

Then, in either case, the declaration instance Num (a->b) where . . . will cause an error to 
be detected since the resulting CHR program is not confluent, rj 

In general there are considerable problems supporting overlapping class instances. The key 
thing to understand is that confluence of the resulting CHRs gives the behaviour we expect. If 
the resulting CHR program is not confluent, then there is an error with the program's class and 
instance definitions. If the CHR program is confluent it doesn't mean there are not problems, but 
at least the correctness of types is not affected by the overlapping instances. 

Example 11. Consider the program 

instance A t => C Bool t where . . . 
instance B s => C s Int where . . . 

The question is what should happen for class constraint C Bool Int. If Bool is in B and Int is in 
A, then it is clear that the constraint holds, we must simply choose which instance's methods to 
use. If we allow overlapping class instances, this leaves the fundamental problem of how to make 
this choice, rj 
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Record Types 

We can define an extensible record type class by using a set of types for labels, and two class 
constraints: 

class Rec rib where 

select : : r -> 1 -> b — access record r, b = r.l 

update : : r -> 1 -> b -> r — update record r so r.l = b 

class Rec r2 1 b => Ext rl 1 b r2 where 
extend : : rl -> 1 -> b -> r2 

The Rec constraint constrains r to be a record type containing element labeled I of type b. The 
Ext constraint constraints r2 to be a type obtained by extending rl with a new element labelled 
I of type b. There are some obvious rules we want to hold in order to enforce type correctness. 

class-defn @ Ext I b r 2 => Rec r 2 I b 

functionality @ Rec r I b\, Rec r I b 2 ==>■ b\ = b 2 

false-extension @ Ext r\ I b\ r 2 , Rec r\ I b 2 False 

extension @ Ext r\ l\ b\ r 2 ,Rec r 2 l 2 b 2 =^> h i= l 2 \ Rec r\ l 2 b 2 

Consider the code 

f x = (select x (A), select x (B)) — (X) is unique element of type X 
g x y 1 = extend y 1 (select x 1) 

h x y = if x == y then [select x (A), select y (B)] else [] 

The (simplified) type constraints for /, g and h are 

/ :: (Rec t x A t fl , Rec t x B t h ) => t x (t fl , t h ) 

g :: (Rec t x t t t s ,Ext t y t t t s t e ) t x ^> t y \-> ti t-^ t e 

h :: (Rec t x A t e , Rec t x B t e ) => t x \— > t x i— > [t e ] 

8 Conclusion 

We have demonstrated that constraint handling rules are a useful tool in understanding type class 
systems. Several existing type class systems can be expressed in terms of CHR rules. Surprisingly, 
constructor classes and multi-parameter classes which have been considered to be orthogonal ex- 
tensions are both expressible in terms of CHRs. Other useful extensions such as disjoint classes 
can also naturally be expressed in CHRs. Feasible type inference and unambiguity are important 
issues in the design of a type class system. CHRs allow us to characterize sufficient conditions 
under which we can retain both properties. We conclude that CHRs offer a natural way to study 
type class systems. In this work, the development was rather motivated by examples and intuition. 
We are currently working on a more formal treatment which we will report separately. 
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